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(57) Abstract ! 

The invention provides methods and appara- 
tus for generating, from a source signal defining a 
subject class to be tested (40), an inspection sig- 
nal defining an inspection class (34) that has one or 
more members for (i) generating a test object as 
an instantiation of the subject class or a class de- 
rived therefrom, (ii) invoking one or more of the 
selected method members of the test object, and (iii) 
generating a reporting signal based on an outcome 
of invocation of those members. The inspection 
class, as defined by the inspection signal, can in- 
clude one or more method members (500, rcfenai 
to as "inspection members", for testing correspond- 
ing method members of the test object (and, there- 
fore, in the subject class). So-called "test suite mem- 
bers" (50a-50e). that are also defined as pan of the 
inspection class, exercise the inspection members. 
The invention also provides methods and apparatus 
for responding to an inspection signal to create an 
inspection object instantiating the inspection class. 
Members of the inspection object are invoked to cre- 
ate the test object (80), to invoke method members 
thereof and to generate a signal reporting an effect 
of such invocation. The test object members can be 
invoked by corresponding inspection members of the 
inspection class, which in turn can be invoked by lest 
suite members of the inspection class. 
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METHOD AND APPARATUS FOR TESTING OBJECT-ORIENTED 
PROGRAMMING CONSTRUCTS 

Reservation of Copyright 

5 A portion of the disclosure of this patent document contains material which is subject 

to copyright protection. The copyright owner has no objection to facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

10 BACKGROUND OF THE INVENTION 

The invention described herein pertains to digital data processing and, more 
particularly, to methods and apparatus for testing object-oriented programming constructs. 

There are many competing factors determining how an organization tests its software. 
In the commercial environment, this includes allocating development resources, motivating 
15 developers to write unit tests, and maintaining those tests over the lifetime of the product. 
The central problem is focusing limited development resources on the unique aspects of unit 
tests, minimizing the overhead of creating test environments and packaging. Secondarx' 
factors include choosing which techniques (state-based, boundary analysis, etc.) are 
applicable to validate each production imit. 

20 Traditional unit testing validates the function points within a software product to 

verify the correcmess of its operation. Often, the strategy is to write a dedicated test program 
for each unit, requiring separate test control and execution, set up of the test environment, and 
production of output to describe the execution of the test, as shown in FIGURE 1. 

Implementing this strategy is often informal and ad hoc. Frequently unit testing is 
25 abandoned because of the difficulty of this approach. When a developer determines that 
some code does need unit testing, he will create his own test harness, writing code to set up 
the test environment, run the test case, output the results and shutdown the test environment. 
The developer is concerned about all support issues, such as memory management, output 
device control and formatting, and initializing and cleaning up the application-specific 
30 environment. The actual test code is generally a small percentage of the entire unit test. 

This practice also tends to be invasive, where conditional test code is added to the 
production code to aid in debugging. Typically this code consists of commands to output the 
value of variables, trace the execution of the code and perhaps validate the state of the 
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Current research into the testing of object-oriented programs is concerned with a 
number of issues. The black-box nature of classes and objects implies that a black-box 
testing technique would be beneficial. A number of black-box approaches have been 
developed, including the module validation technique of Hof&nan ei al ^'Graph-Based Class 
Testing," PrQCecdinPS of the 7th Australian Snfhv;»rP F nyinPPnng Pny^fr ^^n^^ AS WEC 
(1993) and "Graph-Based Module Testing," Proceedinps n f the 16th An<;traHan Computer 
Science ConfgrenCfi , pp. 479 - 487, Australian Computer Science Communications, 
Queensland University of Technology, and the ASTOOT suite of tools by Frankl et al, 
"Testing Object-Oriented Programs," ProceedinPs of the Rth Parifir Northwe<;t Confer^nr^ 
on Software OUf ^ liry , pp. 309 - 324 (1990). Both of these techniques concentrate upon the 
modular nature of object oriented programs. However Fielder, "Object-Oriented Unit 
'Testing," Hewlett-Packard JoumaK pp. 69 74, April (1989) notes that a more adequate testing 
technique can be gained by combining black-box testing with the use of a whitebox coverage 
measure. 

In view of the foregoing, an object of the invention is to provide improved methods 
and apparatus for testing object-oriented programming constructs. More panicularly, an 
object is to provide such methods and apparatus for testing classes in object-oriented 
programs and libraries. 

A related object is to provide such methods and apparatus for testing all members of a 
class and exercising each member over a full range of expected runtime parameters. 

Still another object is to provide such methods and apparatus for implementation in a 
wide range of digital data processing operating environments. 

SUMMARY OF THE INVENTION 

The invention provides methods and apparatus for testing object-oriented software 
systems and, more particularly, class constructs that provide the basis for programming and 
data structures used in those systems. 

In one broad aspect, a method according to the invention calls for generating, from a 
source signal defining a subject class to be tested, an inspection signal defining an inspection 
class that has one or more members for (i) generating a test object as an instantiation of the 
subject class or a class derived therefrom, (ii) invoking one or more selected method 
members of the test object, and (iii) generating a reporting signal based upon an outcome of 
invocation of those members, the source and inspection signals can be, for example, digital 
representations of source-code programming instructions of the type typically contained in 
source-code "header" files. 
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selected member methods. Those arguments can, by way of example, be specified 
interactively or generated automatically. 

In a related aspect of the invention, invocation of a member function is reported by 
comparing the results of invocation of a member function with an expected value. In the case 
of disagreement, an error message can be displayed, e.g., to the user console or to an output 
file. By way of further example, the contents of the test object can be "dumped" following 
invocation. Moreover, signals indicative of the results of these and other results of 
invocation, e.g., statistics regarding the number of successful and erred member function 
calls, can be stored in data members of the inspection object. Reporting signals, such as the 
foregoing, generated in accord with the invention can be generated at selected verbosity 
levels. 

Still other aspects of the invention provide an apparatus for testing object-oriented 
software systems having functionality for carrying out the functions described above. 

These and other aspects of the invention are evident in the description that follows 
and in the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the invention may be attained by reference to the 
drawings, in which: 

Figure 1 depicts a prior art strategy for unit testing of procedural code; 

Figure 2 depicts a prior art strategy for testing object-oriented code; 

Figure 3 depicts a preferred computing system for use in practice of the invention; 

Figure 4 depicts a production class and an inspection class according to the invention 
for testing thereof; 

Figure 5 depicts a relationship between the inspection class and test monitor and test 
kernel superclasses, as well as between the test subclass, the production class and the 
production superclass; 

Figure 6 depicts a test suite and inspection methods comprising an inspection class 
according to the invention; 

Figure 7 depicts illustrative states an object can enter under the persistence paradigm; 
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commercially operating system tools in connection with libraries constructed in accord with 
the teachings herein. 



As shown in the drawing, method member I_Class::A takes arguments and returns 
5 values identical to those of corresponding member A. Member I_Class::A takes, as an 

additional argument, a pointer to a test object created from the production class or a test class 
derived therefrom. As further shown in the drawing, method I_Class::A includes instructions 
for invoking member A of the test object, as well as for reporting invocation, arguments to. 
and return values from that member. Thus, by way of example, where member A is declared 
10 as follows: 

bool A(Int argl); 

I_Class::A can be declared as follows: 

bool 

I_CLASS::Class:: A(P_Class* Obj, 
Int argl) 

{ 

AnnounceStartC'A"); 
AnnounceParameter(arg 1 ); 

bool tstVal = Obj">A(argl); 
AnnounceRtnValue(tstVal); 

AnnounceEnd("A"); 
retum(tstval); 

} 

Each of the inspection methods take the object under test as a parameter, as well as 
15 the rest of the parameters necessary for the production method, as shown in FIGURE 4. This 
not only reduces cut and paste code, but also eliminates the need for specialized test code in 
the production class that is used only during unit testing. It is much preferred to have 
instrumentation outside of production code rather than compiled in, even if the compilation is 
conditional. 

20 The inspection class methods are capable of ruiming against code built for general 

release as well as development and unit testing. With a "dump" method enabled during 
development, unit tests facilitated by the inspection class provide a white-box testing 
environment, allowing the developer to be most effective in determining corrective actions 
for failed tests. Black-box test techniques are in effect when the dump method is disabled for 



// report start of test 

// report parameters that will be 

// passed to member to be tested 

// invoke member 

// report member result 

// report end of test 

// return member result 
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Given a set of inspection methods 36a - 36c grouped into an inspection class 34, 
common services of test output and test environment maintenance are provided by test 
instrumentation base classes 46, 48. The kernel test class 48 allows infrastructure objects to 
be tested in isolation. It provides services for output verbosity control, output formaning, 
5 memory management leak detection and reporting, expression checking, and reporting of 
errors encountered. 

The monitor test class 46, derived from the kernel test class 48, provides additional 
services to application classes such as application environment initialization and cleanup, test 
case setup and cleanup, gross level coverage measurement and reporting, and unit test 
10 execution. 

Organization of Test Suites 

Source code and header files providing definitions of the inspection class 34 and test 
subclass 40 are preferably generated automatically from a header file defining the production 
class. This results in a reduction in the amount of code the developer needs to write in order 
15 to insure thorough testing of the production class. This section examines the definition and 
interrelationship of unit tests within the inspection class. 

Unit tests must achieve a certain minimum standard of coverage. This is ensured by 
dividing the set of production class methods, e.g., 32a - 32c, into groups according to 
behavior and testing technique, taking into account dependencies between various groups. 
20 For example, all methods depend on the constructor methods. Referring to FIGURE 6, 
production class 30 methods are tested by the following groups of inspection class tests: 
memory lifecycle 50a, persistence lifecycle 50b, get and set anributes 50c, operator members 
50d, and semantics 50e. 

Memory lifecycle tests 50a exercise those methods of the production class which 
25 affect the life of the corresponding object in memory. These include the constructors, copy 
constructors, destructor and assignment methods of the production class. Generally, errors 
which occur in the lifecycle are memory leaks and improper initialization. Lifecycle tests 
involve creating test objects (based on the production class, or the test class derived 
therefrom) using each constructor in the production class 30, assigning objects (e.g., in the 
30 case of copy constructors), and deleting the test objects from memory. Checks are then made 
for leftover allocated memory. 

Persistence lifecycle tests 50b exercise those objects that are stored in a database (e.g., 
on disk 22) for later retrieval or storage across invocations of the product. A state-based 
testing approach is used for persistent methods. The states defined in the memory and 
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Durham to address some of the problems in adapting testing techniques to object-oriented 
programming, and is described in Turner et al "The Testing of Object-Oriented Programs/' 
Technical Report TR- 13/92. University of Durham, England (1992). 

An object's behavior is defined by the code within its operations. Events and 
5 situations occur that have to be communicated to the other operations of the object. This 
communication is usually performed by storing specific values within the attributes of the 
class. State-based testing models these interactions as a finite-state-automata which is then 
used to predict the response of each operation to a particular state. 

Test cases are generated to validate that at no point in an object' s lifetime can it be 
10 placed into an undefined or incorrect state. All operations are validated for the state changes 
which they are defined for, operations can also be validated for their robustness when faced 
with an illegal state situation. 

An example deals with persistent classes. Persistence is implemented by a root 
persistent class from which all persistent objects are derived. The persistence paradigm 
15 requires six states that an object can enter: 

New - the object was created and exists in memory only 

Saved - the object exists in the database and not in memory 

Open for Read/Write - the object exists (and is identical) in memor)' and the database and the 
client may save changes to the object 

20 Modified ReadAVrite - the object exists in memory and the database with different values and 
the client may make changes to the object 

Open for Read Only - the object exists (and is identical) in memory and the database and the 
client may not make changes to the object 

Deleted - the object does not exist in memory or the database 

25 FIGURE 7 illustrates some of the legal transitions between these states. Thus, for 

example, an object may transition fi-om a New state 52a, or a Modified Read/Write state 52e. 
into a Saved state 52b. From that state 52b, an object may transition to an Open Read Only 
52c or an Open Read/Write state 52d, whence it may transition to a Deleted state 52f An 
object may also transition into a Deleted state from the Modified Read/Write state 52e. 

30 Since the root persistent class is inherited by all persistent classes, these classes share 

the above states 52a - 52f, although the implementation is made specific to each class by 
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prototypes corresponding to those in the file 62b. Those skilled in the an will appreciate that 
the teachings herein are likewise applicable to other programming languages including 
object-oriented constructs, e.g., Turbo Pascal. Likewise, it will be appreciated that the 
information in the files may be input or output in other formats (e.g., object code) known in 
the art. 

The st;uements contained in files 62a, 62b define the inspection class 34 to include 
members that (i) generate a test object as an instantiation of the test class, (ii) invoke selected 
method members of the test object, and (iii) generate a reporting signal based upon an 
outcome of invocation of those members. 

The inspection class 34 particularly includes inspection members (also referred to as 
"inspection" members) that test corresponding method members of the test object. Thus, for 
example, the inspection class 34 includes inspection members, e.g.. 36a - 36c. corresponding 
to, and taking similar arguments to, constructors, destructors, operators and other method 
members, e.g., 32a - 32c, in the test object. To facilitate testing, the inspection members 
(apart from constructors and destructors) have fiinction names similar to those of the 
corresponding method members of the test object that they test. 

The inspection class 34 defined by files 62a, 62b also includes test suite members that 
invoke or exercise the inspection members for test purposes. The test suite members 50a - 
50e that test accessor, transformer, operator or semantically unique members of the test 
object, as well as the persistence of the test object and memory leaks associated with its 
creation or destruction. A "test main" member 50f invokes the test suite. The inspection 
class provides, via inheritance from die test monitor class and test kernel class 48. members 
50f that permit uniform tracking and reporting of test coverage and errors. 

The statements in files 62a, 62b also define a test class 40 that derives from the 
production class 30 and, therefore, inherits members, e.g., 32a - 32c, therefi-om. The test 
class 40 duplicates pure virtual fiuictions of the subject class 30. absent programming 
constructs that denote those functions as having both pure and virtual attributes (e.g., the 
"pure" and "virtual" keywords). The test class 40 affords the inspection class members, e.g.. 
36a - 36c, access to members, e.g., 32a - 32c, of the subject class, e.g., via C+-i- friend 
declarations. 

Generation of the inspection class header and source files 62a, 62b by the ICG 58 may 
be understood by reference to the Appendix A, providing a listing of a sample production 
class header file 60 named "utg.hh"; Appendix B, providing a listing of a sample inspection 
class header file 62a named "i_utg.hh" that is generated by tiie ICG 58 fi-om file 60; and. 
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9. The start of the public member functions (and member data) are signaled by the 
"public" keyword. The keywords "protected" or "private," or the close of the class 
declaration "};" end the public section. C++ permits multiple public sections within a class 
declaration. 

5 10. ICG 58 ignores enumerations, indicated by the keyword "enum." 

1 1 . Constructors. C++ permits more than one per class. C++ also permits consuiictors to 
be overloaded. 

12. Copy Constructor. If provided, there is only one. A copy constructor has as its first 
required argument a reference (&) to an instance of this class (usually declared const). In a 

10 preferred embodiment, there is a second, optional argument, a memory manager defaulted to 
NULL. All classes must have one, but they can be private and unimplemented. 

13. Destructor. The definition of most classes include a public destructor. 

14. Assignment operator. All classes must have one, however, they can be declared 
private and not implemented. 

15 15. Conversion operator. This operator, also knowTi as cast, is provided in addition to the 
operators defined by C++. This operator returns an object of the type identified in the 
operator statement (e.g., dtULong). Also notice, this member function is const, which is not 
used in generating the signature of the inspection member function. 

1 6. The addition assignment operator returns a reference to an object of this class type. 

20 17. A static member function (sometimes called a class function) returning an erStatus 
object. A pointer to a production object is an output parameter. The static specifier is not 
included in the corresponding statement in the inspection class files 62a, 62b. 

1 8. Public member data is ignored when generating the inspection class files 62a, 62b. 

1 9. The start of the protected member functions (and member data) is signaled by the 
25 "protected" keyword. The keywords "public" or "private." or the close of the class 

declaration "};" ends the protected section. C++ permits multiple protected sections within a 
class declaration. 

20. An overloaded index operator implemented as a const member function. Again, note 
that the const is ignored for the generated inspection function. 
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4. The inspection base class declaration is included by the statement #include "idt- 
lest.hh". 

5. The production class header is included by the statement #include "utg.hh". 

6. Inspection class comment. The lAUTHOR, 'REVIEWER, and !REVIEW_DATE 

5 keywords and values are defaulted from a template (values from production class header are 
not used). 

7. The inspection class comment keyword ! LIBRARY value adds an "I J" prefix lo the 
value from the production class comment (I_ER). 

8. The inspection class comment keyword !NAME value adds a prefix to the name 
10 of the class (i_utg). 

9. The inspection class generator 58 places a comment indicating that this file 62a is 
generated by a tool, to wit, the generator 58. The comment is entered in the !TEXT section of 
the class comment, and includes a date, the name of the tool, and the version of the tool. 

10. The test class declaration publicly inherits from its production class to provide access 
15 to protected member functions. The test class name has "s_" prepended to the production 

class name. All member functions are declared in the "public:" section of the test class. 

1 1 . The test class declares the inspection class as a "friend." This allows the inspcciitm 
class to invoke protected (and public) member functions on the production class. 

12. Test class constructors and copy constructors are declared and implemented inline 
20 replicate the public and protected interface on the production class. The private inicrlaLC 

the production class is not used. 

13. Declaration to satisfy the compiler for a pure virtual member function declared in ihc 
production class. The declaration has lost its pure specifier (=0), but not its const function 
specifier. Also, the virtual specifier from the production class is also not needed (if it is eas\ 

25 to strip off, do it, otherwise the virtual specifier can stay). A comment is generated as an 

indication to the unit test developer that an inline implementation may be required (if linking 
causes this function to be unresolved, i.e., it is being called by some object). 

14. An enum named FUNCS contains entries for each inspection function and a final 
entry named TOTAL_FUNCS. Each entry is composed of a prefix of f_, followed by the 

30 name of the inspection function. Where functions are overloaded (e.g., multiple constructors) 
it is necessary to append a number indicating which of the functions this enumeration applies. 
TThis enum is used for calculating base coverage analysis. 
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24. Assignment operator inspection function. The first argument, as a general rule for all 
member functions, is a pointer to an instance of the test class, followed by the arguments 
from the production class assignment operator. The return type is modified to return a test 
class (s_utg&) instead of a production class (utg&). The suggested name for this operator is 
oper_equal. 

25. The conversion operator must return an object of the same type as the conversion. 
Since a conversion operator itself has no arguments, the only argument becomes a pointer to 
an instance of the test class. The suggested naming for conversion operators is 
oper_<conversion-type>. 

26. The addition assignment operator modifies the return type to a test class, and inserts a 
pointer to an instance of the test class, followed by the arguments defined by the production 
class. The suggested naming for this operator is oper_plusequal. 

27. The static production member function has lost its static specifier in the inspection 
class. Also, production class parameter type has been replaced with the test class. 

28. The index operator follows the same general rules as described for the assignment 
operator. The suggested name is oper_index. 

29. The virtual setID member function contains a default argument, which is a constant 
pointer to a constant object. The virtual specifier from the production class is not needed on 
the inspection class (if it is easy to strip off then do it, otherwise the virtual specifier can 
stay). A pointer to an instance of the test class is inserted as the first argument, with the 
production class arguments following; including the default argument (=(const dtChar* 
const) NULL ). 

30. The start of the "private" section, and the end of the "public" section. 

3 1 . Declaration of the inspection class' copy constructor and assignment operator member 
functions. These are not implemented in the inspection class source file 62b. 

32. Nonclass functions are declared outside of the inspection class. Their return type and 
arguments are preserved (a pointer to an idtTest object is inserted as the first argument, and 
production class types are modified to test class types). The name is changed so it does not 
conflict with the production header nonclass function name. A suggested naming scheme for 
nonclass functions is <inspection-class-name>_<nonclass-function-name>. For example, 
export becomes i_utg_export. 
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1 4. Invoke newlnstance using nim, substitute test class name. In further embodiments, a 
constructor/destructor lest (TLIFE^START through TLIFE_END) can be generated for each 
existing production class constructor. Likewise, they may include argument types in where 
/♦PARAMETERS,*/ currently appears. 

5 15. Copy as is. 

1 6. Invoke newlnstance using mm, substitute test class name. 

1 7. Invoke copylnsiance using mm2, substitute test class name. In further embodiments, 
a constructor/destructor lest (TLIFE_START through TLIFE_END) can be generated for 
each constructor/copy constructor combination. Likewise, they may include argument types 

10 in where /* PARAMETERS,*/ currently appears. 

18. Copy as is. 

19. Invoke newlnstance using mm, substitute test class name. 

20. Invoke newlnstance using mm2, substitute test class name. In further embodiments, a 
constructor/destructor test (TLIFE_START through TLIFE_END) can be generated for each 

15 constructor/assignment operator combination. Likewise, they may include argument types in 
where /*PARAMETERS,*/ currently appears. 

21. Copy as is. 

22. Three invocations of newlnstance using mm, mm2, and mm. Substitute test class 
name. 

20 23. Copy as is. 

24. Invoke newlnstance using mm, substitute test class name. 

25. Copy as is. 

26. Operators testing comment, copy as is. 

27. Operators testing body skeleton, substitute inspection class name for scope name 
25 (i_utg: :t_Operators). 

28. Comment and body for set and query tests. Same rules as requirement 27. 

29. Semantics testing comments and body. Same rules as requirement 27. 
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45. Another version of requirement 43, this time a testVal is being returned. 

46. Nonclass functions have a pointer to an idtTest passed in as the first argument. This 
pointer is used for invoking the announceXxxx member fiinctions. This is done because 
nonclass functions are not member functions on an inspection object (an inspection object is- 
a idtTest object). 

Generation of the inspection class header and source files 62a, 62b by the ICG 58 may 
be fiirther understood by reference to the Appendix D, providing a listing of sample 
production class header 60 named "basresc.hh"; Appendix E, providing a listing of a sample 
inspection class header file 62a named "i__basres.hh" that is generated by the ICG 58 from the 
file basresc.hh; and, Appendix F, providing a listing of a sample inspection class code file 
62b named i_basres.cc that is also generated by the ICG 58 from the file basresc.hh. 

The code generation operations revealed Appendices D - F include support for basic 
persistence testing of a persistable (or persistent) object is the body using the ^'t_persist()" 
function and two additional support member functions for setting up valid user keys and 
persistent objects. 

The items listed below refer to the annotations made on the listings in Appendices D - 
F. In the description of each item, reference is made to the three classes involved in the unit 
test: 

1 . The source production class 30, which is a concrete persistent class. 

2. The test class 40. This is a generated typedef which provides access to the public 
member functions of the production persistent class. 

3. The inspection class 34. This class performs tests on instances of the test class 40. 

As above, where dictated by context, references in the explanatory items below to the 
'^production class," the "inspection class" and the "test class" shall be interpreted references 
to the corresponding files 60, 62a, 62b. 

Explanation of Annotations to Production Class 
File 60 Listing nf ApppnHir n 

1 . User Key class name. A user key is a class that contains text which is the name of a 
persistent object. This can be obtained from scanning the second parameter type of the 
openForChangeO, openForReview(), and saveAs() member functions. In an alternate 
embodiment, a hint as to the icg is obtained from the production class developer via a 
lUSERKEY keyword. 
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9. The qryCoverage member function, which is currently being generated. 

10. The user key setup member function body, setupUKs(). This is copied as is, except 
where noted in 11 . 

1 1 . User key argimients for setupUKsQ requires substitution of the user key class name. 

5 12. The persistent object setup member function body, setupObj(). This is copied as is, 
except where noted in 13. 

13. Test class pointer argument for setupObjO requires substitution of the test class name. 
Unit Test Harness 

With continued reference to FIGURE 9, the inspection class source file 62b 
10 generated by ICG 58 is compiled, linked and loaded (see element 64), along with production 
class header and source files 60, 68, as well as library files containing the test monitor class 
definitions 70 and the test kernel class definitions 72. Compiling, linking and loading is 
performed in a conventional manner, e.g., using a C-h- compiler sold by Microsoft 
Corporation. The resulting file 66 containing executable code for the unit test harness is 
15 executed on digital data processor 12 to reconfigure that processor as the unit test harness. 

FIGURE 10 depicts operation of the unit test harness 74. Particularly, testmain() 
routine 76 creates an inspection object 78 as an instantiation of the inspection class 34 
defined in files 62a and 62b. TeslmainQ also invokes testrun(). The testrun() method 79 of 
the inspection object invokes test suite members 50a - 50e of the inspection object, each of 
20 which (i) creates a test object 80 instantiating the test class 40 (defined in file 62b), (ii) 

invokes a members of the test class, e.g., 42a, via corresponding inspection members, e.g., 
36a, of the inspection class, and (iii) utilizes reporting members 82 of the inspection object 78 
to report results of the invocation of the test class members. Reports can be generated to 
printer 25, to monitor 24, to a file on disk drive 22, or in other media as known in the art. 

25 As illustrated, the test harness 74 accepts arguments, e.g., from the user, for 

application to the test object upon or upon invocation of the selected member methods, e.g., 
42a. Such arguments can, alternatively, be generated automatically be the test harness 74. 

Reports generated by members 82 of the inspection object include those resulting 
from comparing the results of invocation of the test object member, e.g., 42a, with expected 
30 result values. In the case of disagreement, report members 82 cause an error message to be 
displayed, e.g., to the printer, monitor or a disk file. Report members 82 also permit the data 
members of the test object 80 to be *'dump)ed" following invocation. The report members 82 
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TJNIT{ methodname ) - Initialize a t_* method, setting up a test memory manager, mm 

TJ2LEANUP{ methodname ) - Clean up a t_* method, checking the memory manager for 
leaks. 

TEST_START( testname ) - Start a test scenario 

5 TEST_END - End a test scenario; announces whether the scenario passed or failed. 

TEST( testname, expression ) - A combination of TEST_START() and TEST^END for tests 
which consist of a single expression to check. 

checkExceptf expression, id, testname) - Verify that evaluating the expression throws an 
exception with the id indicated. CheckExcept is implemented in systems that do not 
10 otherwise support exception handling by the use of the setjump and longjump ANSI 

functions. Prior to evaluating the expression, setjump is performed to save the current stack 
frame. If an exception is thrown and it is required to restore the stackframe, longjump is 
performed. 

In addition to the foregoing, the inspection object inherits from idtTest the testrun() method 
15 and other code for running the t_* methods and the code for analyzing the results of the unit 
tests. 

Developing Unit Tests 

The sections that follow provide still further discussion of the operation of the 
inspection class generator 58 and unit test harness 74. Also discussed is designer 
20 modification of the inspection class header and source files 62a, 62b for completing test 
suites for the test harness. 

Although inspection class generator 58 creates most of the unit test code 66 from the 
production class header file 60, the scope of testing may necessitate that the developer 
complete implementation of the test and inspection classes, as well as the test scenarios 

25 themselves. As noted above, in order to manage the potentially large number of test 
scenarios, the methods are divided into the following logical groups for testing: 
LifeCycle - creation and destruction of the object (tests for memory leaks) 
Set & Query - Accessors and transformers of the object 
Operators - Operator methods 

30 Persist - methods involved in object persistence 
Semantics - methods unique to the class. 
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Noie that the destructor is tested along with the constructor in these cases. The basic 
test is illustrated in Appendix G. 

Also note the use of the test class, s^erMsg, in this example. The test class should be 
used to represent the production class in all unit test code. 

Another consideration in constructor operation is their behavior under error 
conditions. Usually this means testing consuuctors when there is insufficient memor>' for the 
new object. 

In one embodiment, out-of-memory exceptions are thrown by the memor>' manager, 
and caught at the application level, so object constructors are not involved. However, 
constructors may require parameter testing. 

Parameter testing should be performed when a parameter's value has some restrictions 
which are enforced by the constructor. In this case, use equivalence partitioning and boundar\ 
value analysis to determine the necessary test cases. For example, if an object had a member 
which was an unsigned integer, but the only legal values were in the range 1 - 1 00. In this 
case, test cases need to include calling the constructor with the values 0 (invalid), 1, 50, 100, 
101 (invalid) and 500 (invalid) might be used. 

If the parameters are pointers, test cases should be written to check behavior when the 
parameter is NULL. A test case to check the default constructor needs to be uxitien a.*; well. 

Copy Constructor Testing 

Testing the copy constructor follows the form of tests for the regular constructors, 
with slight modifications. In particular, the constructed object should be in a different 
memory area than the copied object to ensure that the copy is completely independent of the 
original. Referring to Appendix H, the scenario is as follows: 

1 . construct an object (obj 1 )with memory manager nun 

2. construct the test object, by copying (obj2)with memory manager mm2 

3. check the equality of the objects (if an equality operator exists) (obj 1 =obj2) 

4. delete the original object (obj 1 ) 

5. announce the test object (obj2) 

6. delete the test object (obj2) 

Note that deleting the original object catches errors involved with incomplete 
copying. TLIFE_END check both memory managers for leaks. The copy constructor needs to 
have a test case for each constructor. 



wo 96/12224 PCT/US95/06059 

.31- 

Testing Set and Query Methods — t^SetQrys 

The purpose of t_SetQrys is to test the operation of the accessors and transformers of 
the class; this includes the Query, Set and Validate methods. 

Query Methods Testing 

The query methods should be tested first, because they can then be used to test the Set 
methods. There are two approaches to testing the Query methods. If the method returns an 
unaltered value, the approach is to create an instance of the class with a known value in the 
member(s) being queried, and then check that the query returns these values, as illustrated in 
Appendix I. 

Note the use of the TEST() macro; the TEST() macro combines TEST_START(), 
checkExprQ and TEST_END macros, allowing a test which consists of a single expression to 
be tested in a single line. Since the example test case consists of the expression, "fdMsgTesi3 
== qryMsgID( msgl )", the test can be implemented as a call to this macro. 

The number of test cases that are needed to validate a query method depends on the 
complexity of the query and boundary conditions. In some queries, the member being 
queried may not be present; remember to test both the positive (member present) and the 
negative (member absent) cases, as illustrated in Appendix J. Null and 0 are the most 
common boundary values; always consider whether test cases for these need to be uritten. 

Another consideration occurs when the value being queried undergoes some 
transformation either at creation or during the query. In this case, additional test cases would 
need to check the special cases, assumptions, or boundaries that the calculation imposed on 
the data. For example, a date class which stored its value in terms of month, day, year, but 
included a method qryDayOfY ear() which calculates the number of days since the start of the 
year. This method adds to the class of valid test data the conditions of leap and non-leap years 
(and skipped leap years at century boundaries), and the special case of the year 1 752; test 
cases need include February 29 and December 31, for both a leap and non-leap years, dates in 
the skipped leap years, such as 1900, and dates in 1 752 (depending on locale). 



There are no restrictions in setting up test data which satisfies several query unit tests 
at once, as shown in Appendix J. 
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operator dtULongO const; 

This is tested in i erMsg as follows: 

// 

// Test 1 : Cast to dtULong 

// 

const dtULong test lvalue = 1 ; 

s_erMsg* msgl = newlnstance( testlvalue, ERMSGTEST^NAME, ERMSGTEST_5, 
_FILE_, _LINE_, mm ); 

// Do cast and check the value 
TEST( "Cast to dtULong'*, testlvalue = oper_dtULong( msgl ) ): 

deletelnstance( msgl ); 

Testing Object Persistence — t_Persist 

The purpose of t_Persist is to test the object persistence for the class: this includes the 
Persist and Fetch methods. 

Testing Unique Methods — tjSemaniics 

The purpose of t^Semantics is to test those methods unique to the class. 
Test Execution Code 

The inspection class generator 58 creates the code which allows the single unit test 
harness 74 to run the tests. The harness 74 collects arguments from the user lo run the icsi 
Then, the test harness 74 calls two exported routines: testnameQ and testmainO, to ftuurc ou\ 
what is being tested and to execute the tests. testnameQ returns a dtChar ♦ which names the 
inspection class. testmainQ serves as the top level of test execution, calling testrun() which, 
in turn, calls inspection class methods which test the production class. In the inspection 
class, two macros are used, TESTRUNdecIare and TESTRUN (supplied in idtTest 46). so thai 
testmain is not coded directly. Implementation of these routines is illustrated in Appendix K 
in which the class "erMsgi" refers to the class "i_erMsg." 

Once the inspection class code has been written, it is built into a dynamic link librar>'. 
or "DLL." Each inspection class must have its own DLL, so that the testnameQ and testrunQ 
routines do not clash. 



wo 96/12224 



PCT/US95/06059 



-35. 



Verbosity 


Class 


kjoxiipic iViCoSages 


SKIP 


Skip particular test 


SKIPPING: t_LifeCycle, verbosity set to SKIP 


OFF 


None 




LOW 


Error messages 


c.r%jvv^i\.. in lesi ruu, rue rlLh, Ime LINE, 
bad expression: EXPR 


MED 


Status messages 


Starting test FOO 
PASS: FOO 


HIGH 


Object dumps, other 
debug messages 


Current value of mDate: FOO 



If the user sets the verbosity level to OFF, the unit lesis will not output any messages, 
but if they set the verbosity level to MED, they will get the error and status messages in the 
output log file. Appendices L, M and N depict of test runs at the various verbosity levels. 
SKIP allows execution of a test suite to be skipped, e.g., for purposes of initial test 
development and debugging. 

In addition, the inspection class appends a simple analysis of the run at the end of a 
unit test execution. testmain() always returns the number of errors detected, so the test 
harness can display this information even with the verbosity level set to OFF. At LOW and 
MED verbosity levels, the unit test code 74 reports on the number of tests run and the number 
of errors found. At HIGH, coverage information is output; this allows the user to determine 
whether all of the production methods were tested. 

Unit Test Output Files 

Output by harness 74 and, particularly, by reponing members 82 is placed into fi\c 

files: 

Log file: <file>.out (<file> represents the destination file field in the unit test harness) 
Error file: <file>.err 
Memory Log file: memory.log 
Exception Log file: except.log 
Database Error file: sqlerror.log 

The log file is the main file for unit test output. All of the output generated by the unit 
test code is placed into this file, giving the user a place where they can read the messages in 
context. As described above, the contents of the log file is controlled by setting the verbosity 
level. 

The error file separates the error messages fi-om the rest of the output for easier 
management. It is not affected by the verbosity level; it always contains all of the error 
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// FILE^NAME: (^Iphh \ 
// Copyright 1993 by Marcam Corp., Newton. MA USA 

// This unpublished copyrighted work contains 
// TRADE SECRET information of Marcaa Corporation. 

// Use, transfer, disclosure, or copying without 
// Its expressed written permission is strictly 
// forbidden. 
// 
// 




*ifndef utgHH 
»c3efine utgHH 



• include 'dtcorchh^ 4" 



// For dtCore 



Jl !LIBRA»X<||^ Co 

J I !NAME/ucgy _ 

U nS™hPr%rH'f^^" generator. This class header attempts 

// 5h-n cre«?^ rL f that need to be transformed 

II cublic fnd n?„r2 r^S^P*"^'"",^^*" header. This includes the 
// , protected wember functions, operators, static and nonsta-ic 

J, a!^o vI"ious°sf;i«'' J"""'"" functions appearing in a header 
// are tested ^ """^ ^^""^ ^ function delcaration 

// 

// iR^™-:, ""f " <dalton9opl.con,) 
// IrI^I^Idate :d«er"'" <'Heviewer-s E-mail address, > 

'''''''''niniiiii^u/iiiiiiiiiiiiiiiiiniiiiiiiiiiiinnniiiiiuinii 

class EXr-OST ^t^Ti" public dtCore 
public:— ^ 

enui^"str^n"f^!"^*" "''^ ^"'^ "P inspection class. 

( 




); 



ro stringSize ^"V,^^ 
STRINC.SI2E = lOy fO 



Most classes are 



// JNAME utg def ctor 
// .'TEXT 

// The default constructor. 
// required to have one. 

utg( dtMemoryMgr* aMemMgr ); 

//'(m^hodIde^^^ 

// iNAME utg^ctorl 
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_vitQt_ operator ( dcint aRhs); 

// !NAME utg_openForR«ad 
// ITEXT 

// Static method generates a utg 

n fS^lt'J^^f " - inspection 

Jitnujniimj/ijiiiu/iminimmiiuiiiiu 



static erstatus openForRe«d{ uto't aUtg. dtMemoryMgr- aMM 




//public n-J^r^d-ta. Should not appear in generated in= 
dtChar publicIDstring | STRlNC_srzE) ; 



protected: 



'//'■M^'^'Jd^JJ^"""" 

// !NAME utg_operator| J () 
// ITEXT 

// An overloaded index operator 

""'^nn/N/nniiiiiiiiiiiiiitiiniiuiiimii 

dtChar operator I)( dtlnt aindex ) const ? 
V/\y!Jr[^o:!':!zcx!'s'' '''''''' '''''''''''''''''''''' 

n !NA,M£ utg.-^cilD 
// iTEXT Hn 

makp^^J^ ^ ^w^^ virtual nember function. 
// makes this an abstract class. These don't 

// declared (as private) in the inspection class 

/ class)'''L"^^:^''"*^ (inst.ntiating'an abstract 
// Class). No source is generated for this, it 
// can be ceclared and implemented 

virtual dtULong rtnlDO const = 0; 





// !NAME utg_setID 
// !TEXT 

// vT^/^? 2b/ has an optional parameter, 
// Virtual function declaration is not uied 

"^^'^ function 

virtual dtBoolean set ID ( const dtULong alD 

const dtChar* const aName 1 (const dtChar* 



•if del OPUDEBUC 

H !NAME utg dujsD 
// STEXT 

'I'l J!!iL^f ^ announceXXXO methods so 

// there is no need to include this in the 
inspection class. 

"'^innjuminnnitijiinnniimnnuim 

dtvoid du»p(dtOStr.an,t aOutStream, dtUInt aIndentLevel 



0) 
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//////////////// //// ////////////////////////////////////////////////// 
// F2LELNA>1E: ^_utphh3 
// Ccjpyright 1993 by Marcam Corp. 

y/ 

// This unpublished copyrlghccd work contains 
Ji TRADE SECRET Inforraation of Marcan Corporation. 
// 

// Use, rransfer, disclosure, or copying without 
// its expressed written permission is strictly 
// forbidden. 
// 
// 

/////y///y ////////////////////////////////;/////////////////////////// I 



tifndef l.utgHH 
♦define i_utgHH 



> 



finclude •idttest.hh* 
♦include "utg-hh* 



// For idtTest --^ 
// For utg ^ 



1 



///////////////////////////////////////////////////////////////////////// 
// iCLASS_DECL_S 
// iLIBRARY LER^T 

.'NAME i.UIQ Cr 

// iTEXT ^ 

// Generated 7/12/93 by te/utg version 1-0*^ 
J/ 

// '.AUTHOR <Author*s name> < (Author's E-mail address) > 

// iREVIEWER <Revlewer's name> <(Reviewer's E-mail adGress)> 
// !RrviEW_DATE <date> 

//////////////////////////////////////////////////////////////////////// 




///////////////////////////////////////////////////////////////////////// 
// Class under test. This class is derived from the prcd-jction cb}ec:. 
// This provides access to the public and protected member functions 
// of the production class, without modification to the production 
// class. Also, pure virtual functions declared in the production class 
// are provided an implementation here. This allows production abstrftci 
// base classes to be instantiated and tested. 

///////////////////////////////////////////////////////////////////////// 

class s_utg : public utg 
1 

public: j 

friend class i_utg; I ' 

y//////////////y ///////////////////////////////// • 

// Inline constructors, and copy constructor 
y/ for replicating the production class interface. 

///////////////////////////////////////////////// 

s_urg( dtMemoryMgr* aMemMgr ) : utg( aHemMgr )() 

s_urg( dtULong aArgl, 

const dtChar* const aArg2. 

dtMttsioryMgr* aMemMgr ) : utg( aArgl, aArg2, aMemMgr )() 

s_utg{ dtULong aArgl, 

const dtChar* const aArg2, 
dtlnt aArg3, 

dtMamoryMgr* aMemMgr ) : utg( aArgl, aArg2, aArgl. aMemMgr )( 
s_utg( const s_utgt aS_utg, 
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s_utg* newlnstancet dcMemoryMgr* aMemMgr ); 

s_iJig" nevlnszancel dcULong aArgl, 
const dtChar* const aArg2. 
dtKoDoryMgr* aMemMgr ) ; 



s_utg* n€wlnstanco( dtULong 

const dtChar* const aArg2, 
dtint aArg3, 
dtMeaoryMgr* aMemMgr ); 



aArgl, 



2^ 



///////////////////////////////////////////////// 

// Copy constructor for class under inspection. 
///////////////////////////////////////////////// 

s_utg* copyInstance( s_utg» ainstance, 

dtMemoryMgr* aMemHgr= (dtMeitioryMgr«)NULL) ; 



///////////////////////////////////////////////// 
// Destructor for class under inspection. 
///////////////////////////////////////////////// 

dtVoid deletelnstance ( s_utg» ainstance ); 

y/////////////////// ///////// //////////////////// 

// other member functions. 

///////////////////////////////;///////////////// 




22- 



•s_urgt oper_equal( s.utc* ainstance, 
const s_utgt aRhs ) ; 

■GiULong op€r_dtULong( s_ui5« ainscance )i 

23*-s_utgk oper^plusequal ( s.uLg* ainstance. 
diint aFUis ) ; 



erStatus openForRead( s_ucg*i aUcg, dtMemoryMgr* ar.xTT^Z'^ 

-diChar oper_index( s_ucg* ainstance. 
dtInt a Index ) ; 



7> cz9 



dtBoolean setlDC s_utg* ainstance. 
const dtULong alO.. 

const dtChar* const aName a (const dtChar* const) NULL ) 

private: 

///////////////////////////////////////////////// ^ 
// Inspection class member functions, unimplemented 
// copyconstructor and assignment operator, 
////y//////////////////////////////////////////// 



l_utg( const l_utgt al.utg ); 

i_utgt operator- ( const i_utg4 al_utg )i 




///////////////////////////////////////////////// 
// Nonclass functions to be tested. 
///////////////////////////////////////////////// 

dtBoolean iwUtg.export ( idtTesf aTestObj, const s_utgt aUtg ); ^ 3*2- 

s_urgt i_utB.op€r jlus < idtTesf aTestOb j , const s_utgfc aLhs. const s_utgt eRhs );)33 



iendlf // i_utgHH 
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n/ /////////// f/^JJ^^/ /////////// ////// 

// Copyright 1993 by Marcam Corp., Newton, MA USA 
// 

// This unpublished copyrighted work contains 
// TRADE SECJiET information of Marcaw Corporation. 
// 

// Use, transfer, disclosure, or copying without 
// its expressed written permission is strictly 
// forbidden- 
// 
// 

///////////////////////////////////////////////////////////////////;;; 



itijiclude •i.utg. hh* 



// For i.utg 



-J 

lass 4 




// Establish an instance of TESTRUN for this c 
TESTRUNdeclare ( i_utg ) 

// 

// TESTHUNO and testname () are used by the unit test harness 
// to run the tests and display the name of the unit test. 



extern -C* dtlnt FAR PASCAL EXPORT testinain( idtTescArgsi aTescArgs 



) 



returns TESTRlTNd^utg) ( aTescArgs ) ); 



extern "C* dtChar • FAR PASCAL EXPORT testname () 



return ( • i_utg' ) 




/////////// f //////////////////////////////////////////////////// ^ y //// , 

// iCLASS.DES;:^^^^ 7 

// JL:==ARir-ORj 7^ 
// !:;AMsf i.uto^^ 

// !TEX 

// Generated 7/12/93 by utg version 1.0 
// 

// lAL.HOR <Author's name> <(Author*s E-mail address>> 

// 'Rtv/IEWER <Revi€W€r's nanie> <( Reviewer's E-mail ad:Jress)> 

// !REV:ew_daTE <date> 

y//yy/y////y//y/j/////////////////////////////////////////////// ////// // 



1 




^ n n } n f i n a } ! n m n n n n t u f n ill ii I i u n u t 

11 Inspection class constructor. 
///////////////////////////////////////////////// 

i_utg: :i_utg( 

dtStreamExecutive* aStreamExec, 
dtMemoryExecutlvet aMemExec, 
idtTestArgsw aTestArgs, 
dtMemoryMgr* 

): idtTest{ aStreamExec, aMeniExec, aTestArgs ) 



I 



for ( int 1 = 0 ; 1 < TOTAL.FUNCS 
coverage! i] = 0; 



^ J n n 1 1 n t n 1 1 1 1 1 1 li n 1 1 1 1 1 1 n 1 1 1 1 1 n 1 1 1 1 1 1 n 1 1 1 

Ji Ii:spection class destructor. 
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// has a value after assignment) must be tested. 

TLI FE^STAKTf •ctorl and operators* ) 
-~ s_utg* testobjX = newlnstancel /•PARAMrrERS, •/ 

s_u tg* testobjY = newlnstancel /•PARAMETERS. •/ 

r- ^stobjY n •testobJX; 

//iFlX cheOcExprt 'testofajX «= •testobjY, currTest )• 

deletelnstancei testobjX ); 
announceObject ( •testobjY ); 
delet«Instance( testobjY ); 
TLITZJENO 




TLIFE.STAR T ( 'Chained assignment • ) 

s_utg testobjX « newlnstance( /•PARAMETERS,*/ 
s«utg* testobjY = newlnstance( /'PARAMETERS,*/ 
S-VJtg * testobjZ = newlnstance ( /•PARAMETERS •/ 
n^objZ = •testobjY = 'testobj/; 

chec)cExpr( •testobjZ == •testobjY, currTest 
deletelnstance( testobjX ); 
deletelnstancei testobjY ); 
announceObject ( •testobjZ ): 
deletelnstanceC testobjZ ); 
rLIFE.END 



J FIX 



mm 

mm2 

mm 

) ; 



2 2. 



LTfS-START( •Assignment to self ) 

s^tg* testobjX = newlnstance( / * PARAJ<ETERS • / run ) 
T^stob^X = •testobjX: 

announceObject ( •testobjX ); 

deletelnstance( testobjX ); 
-Ir£_END 



rLIFE.CLEAJ^i^iP; 



///■/////////////////////////////////////////;// 

// Operators testing. 
// 

til are tested here. The entire 

// 
// 
// 
// 
// 
// 
// 



set ot operators has been broken into li)ce 
categories for ease of testing. Between the 
T.INIT and T_CLEANUP macros the memory manager 
variable irjn is available for constructing 
test objects. Each individual test must be 
surrounded by the T.START and T END macros, 
or alternately, the test itself can be performed 
within a TEST macro. 



^nn/nntuunnuut/ti/iunniti/tuntfu/ 

<3tVoid 

i_utg: :t_Operators() 

T_INIT( •t_op«rators» ) 

// COMPARISON OPERATORS: < > <s >. b« <= 
// ARITHMETIC 0PE3^T0RS: *-•/%♦♦.- 
// LOGICAL OPERATORS I I I 44 < 
// BITWISE OPERATORS: ^ I 4 - « » 

// EXTENDED ASSIGNMENT OPERATORS: -= *. Ir. |= 4n «. » = 

// CONVERSION OPERATORS: type!) 
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// constructing test objects. Each individual 
// test must be surrounded by the T.START and T.END 
// macros, or alternately, tne test itsel£ can be 
// performed within a TEST macro. 
///////////////////////////////////////////////// 



dtVoid 

l_utQ: :t_Persist {) 

i 

T INIT( -t.Perslsf ) 



//ITIX Add your p>ersistent member function tests here 



T.CLEANUP; 



///////////////////////////////////////////////// 
// Return coverage information. 
// 

// NOTE: This is not to be modified by unit 
// test developers. 

///////////////////////////////////////////////// 



dtVoid 

i_utg: :qryCoverage ( 
dtlnt*li aCovAry, 
dtlntt aNumFuncs 
) const 

I 

aCovAry = coverage; 
aNu-nFuncs = TOTAL_FUNCS; 

} 



///////////////////////////////////////////////// 
// Constructors for class under inspection. 
// 

// NOTE: The following constructors can 
// be r.odified by unit test developers. 

// The parameters for a given constructor, 

// and the announcement ot parameters and 

// resulting objects can be custo.nized 

// by the unit test developer. 

y/////////j///////////////////// ///////////////// 




s_utg* 

i.utg: :newlnstance{ 

dUdemoryMgr* aMemMg 
} 

I 



13 



3^ 



coverage I f .newlnstancel J ; 
announceMethodStart < 'newlnstancel' ); 
s_utg* NewObj = new (aMemMgr) s_utg (aMemMgr) 
announceMethodEnd( •newinstancel* 
return ( NewOb j ) ; ^ 



3^ 



3s 



^7- 



s.utg* 

i_utg: :newlnstance( 

dtULong aArgl, 
const dtChar* const aArg2, 
dtWeaoryMgr* .aMemMgr ) 



coverage I f_n«winstance2 1 ; 
announceMethodStart ( 'newinstance2 • ); 
s_utg* NewObj « new (aMemMgr) s_utgt aArgl, 



aArg2, aMemMgr ), 
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coverage I f_oper_ qual)**; 
announceMechodStart ( "oper^equal* ); 
announceParameter ( aRhs ) 

aInstance->operator= { •ainstance ) ; --^q ^ 
announceMethodEndt •oper.equal* ); 
return ( •ainstance ) ;v " 



dtULong 

JwUtgi : oper.dtULong < 
s.utg* ainstance 

i 



{ 



coverage I t_oper_dtULcng J ♦ * ; 

announceMethodStart ( •oper.dtULong* ); / 
dtULong testVal = alnstance->operator dtULong () ; — — 
announceMethodEnd ( •oper_dtULong' ); * \^ 

retum( testVal ); 



s_utgA 

i_utg: :oper_plusequal( 
s_utg* ainstance. 
dtint aRhs 
) 

\ 

coverage I f_oper_pluseqijal I + * ; 
announceMethodStart ( •oper_plusequal • 
// announcfeParaneter ( aRhs ); 

a2nstance->operator*= ( •ainstance ); 
announceMethodEnd ( •oper.plusequal • ); 
return* 'ainstance ); 



dtChar 

:_utg : : cper_:ndex ( 

s_utg* ainscance, 
dtZnt aindex 
) 

\ 

coverage I f _oper_index ) ♦* ; 
announceMethodStart ( •oper.index* ); 
// announceParameter { aindex T; 

dtChar testVal = aInstance->operator ( 1 (a Index) • 
announceMethodEnd { 'oper.index* ); 
return ( testVal ); 



dtBoolean 
i^utgj :setID( 

s_utg* ainstance, 

const dtULong alD, 

const dtChar* const aName 

) 

I 

coverage | f _set IDl ; 

announceMethodStart ( 'setlD' ); • 
// announceparajneter ( alD ); 
// announceParamater ( aName ); 

dtBoolean testVal « aInstance->setID(aID, aName) : 

announceMethodEnd ( •setID' ); -lu, oname; , 

return! testVal ) ; 
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i^^n I n ! 1 1 J 1 1 n i n I n I n i n I i n i u i n m n i i i a m n ! I i Hi n m / 1 i ! / i n n 

// FIL^JAME: basresc.hh 
// 

// Copyright 1993 by Marcam Corp., Newton, MA USA 

// This unpublished copyrighted work contains 

// TRADE SZCRCT information of Marcam Corporation. 

Jf Use, Transfer, disclosure, or copying without Its expressed 

// wrirten permifision is strictly forbidden. 

// 

/////////////////////////////////////////////////////////////////////// ^ 

♦ifndet basrescHH 
«de£ine basrescMH 



♦include 'geninst.hh* 
♦include •bcdatet.hh* 
♦ include •naineulc.hh* 
♦include "dtbitv.hh* 

cIass DCPORT BasicResource; 



// For fdCenlnst 

// For bcDateTime 

// For fdNameUK 

// For dtBitVeccor (dummy) 



•ifdef OSE.T EM PLATES 

♦include •orb.hh* 

schemacompiler 

• inoiuOw •l^a;:.re3C.h* 



/ / ; CI-fkSS_D£CL_S 
// 'LIBRARY 

// INAME BasicResource 
// .'TEXT 

// BasicRecource is the in^plenencat ion of a generic i"3iar.ce-derived 
// class. This is an independently persistable kmc (I?K). 

// The user's access rights will be checked whenever tdSecur i^yCont ex:: 
// arpearr: as a parameter. If the user does noL have apprcpriace acce-3 
// m thti standard UI/App API, an error message will be returned. 

// A returned pointer to an erMsg or ei*MsgLisi indicates an error 
// occurred. A NULL pointer indicates successful completion of 
// tb« member function. 
//. . 

// JAUTHCfR <Author*s name> <(Author*s E-mail address)> 

// iREVIEWER <Reviewer*s name> <(Reviewer's E-mail address)> 
// iRTVIEWJATE <dat«> 
// 



class EXPORT BasicResource : public fdCenlnst 
publics 

////////////////////////////////>//////////////// 
n !MrrHOD_DECL.S 
// !NAME close 
// !TEXT 

// This static method closes the current object, 
// releasing all database and memory resources. 
// When successful, the aBasicResource pointer 
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BASRESC.HH 



///////////////////////////////////////////////// 

// !METHOD.DECL_S 

// !NAME openforReview 

// :text 

// This static raethoca retrieves an existing BasicResource 

// from the database by its user key in a nonmodif iable 

// mode. If an error occurs the aBasicResource 

// pointer will be set to Null, and an error message 

// Is returned. 

// 

// ••Standard Ul/App API, implemented in stdgi.cc^* 

/////y/////////////////////////////////////////// 

static erMsg* openForReview ( Basic Resource*t aBasicResource, 

constddNameUK^^ ^^cisicResourceUK, 
dbTrans CLJC ' V "^^i. --.x, 
fdSecurityConcext aSe.- .tyctx. 
fdlnstTypes: : type aType. 
dtMemoryMgr* aKM ) ; 

///////////////////////////////////////////////// \ 
// !HrrHOD_DECL_S 
// iNAWE remove 
Jf !TEXT 

// This static method removes an existing BasicR**?:;-^ * 
// from the database. When successful, the 
// aBasicResource pointer is Null (the ob-iect has oeen 
// deleted from memoi-yi. If an error occurs, e.g., 
// validateToRenovet ) fails, then an error message' 
//is returned. 
// 



// •♦Standard UI/App API, implemented in stdgi.cc** 

///////////////////////////////////////////////// 

static erMsgLisf remove ( BasicResource'i aBasicResource, 

dbTransCtx'i aDbCtx. 
fdSecurityConcext aSecurityCtx 1 ; 



'.'/// *'///////////////////////////////////////// 

; caveAs / 

static method saves the current object as a new 
// object using the supplied user key and type. The / 
// original object (aOrigBasicResource) is closed, / 
// and the new object (aNewBasicResource) is saved 
//to the database and remains in memory. Validation 
// errors during save are reported. 

// ''Standard UI/App API, implemented in stdgi.cjr 

//////////////////////////////////////////y///^ 

Static erMsgLlsf saveAs( BasicR^snuraaXAx^NewBasic Re source, 

const ^ dNameUjcJ aBasicResourceUK, 
BasicRaJtiulcQ-i aOrigBasicResource, 
dbTransctx*t aDbCtx, 
fdsecuritycontext aSecurityCtx. 
fdlnstTypes: : type aType, 
dtMemoryMgr* aMM ) ; 

'n\^^ox!j:!zzx!^^'' '''''''''''''' '''''''''''''''' 

// !NAME validateToRemove 
// !TEXT 

// This virtual method (declared pure virtual by fdcenlnst) 

// performs all validation (referential Integrity) 

// reejuircd before removing this object from the database. 



J 



ll/B/93 1:20PM Page : 



SUBSTITUTE SHEET (RULE 26) 



wo 96/12224 



PCTAJS95/06059 



SI 

i_SASnrs.cc 



///////////////////////////////////////////////// 

// Persistence testing. 

// 

// This tests behavior specific to the persistence 

// member functions of e production class. 

// 

// Between the T_INIT and T_CLEANUP macros the 

J : nemcry manager variable mn is available for 

// constructing test objects. Each individual 

// test roust be surrounded by the TEST^START and T£ST_END 

// macros, cr alternately, the test itself can be 

// performed within a TEST macro. 

///////////////////////////////////////////////// 

dtVoia 

i.BasicResource: tt Persist () 
( 

// STt)CIT_TESTCLASS and STDGIT.OEJREF must be esta blish 



// 



*defina ET DC IT J ESTCLASS (s^Ba sicRe source, 
<f define STDGIT_CBJREF ^buo.i ne I -^^^ " 




// At least one ct' the following must be preser.c. 
// 

♦define STDCIT.PROCUCTION 
y/*:define ETDGIT.WIP 
//*tdefine STDCIT.TEMPLATE 
y / ^ d c f i n e STOG Z 7_ I y. ?0?-T_ E X PO RT 




.INIT{ •t.Persirf 



ficNameUK^uV.l ( mm ) ; 

{J^ J f fdN^neUK \j^'2 ( iTjn ) ; 

^f ^;;.v^u:< > jk3 (mm ) .* 



a) 



■ IT.T.ISTCLASE* ob: • = CSTDCIT TESTCLAirS'i irULL 
::7_7£STCLASS- Ct-j'^ = (STDGI7_TE::: CLASS') N"JL*- 
S7nCI7_TES7CLAS3» cb:iJ = ( S7DGI7_7ES7rLi S!; * ) UuLL 
J / / ITjy. You may need zo specify a securiiy cortexi. 

Lf -Security Context security = FD_2C_N'clcc:w EX* ; 
//iriX When ir.pier.ar.ted b v ^"'^^^T.rc rh o J r^;"r^^-f rgcuir&d 
//:?;:•: fcK:ndRef< oObj?.er-' ^55icHesc7rcg > Od::ar:^el^ > Kr; 

^ // Setup the user keys for the 3 H-2^t--^:*ects 

setupUKs( uKl» u>:3, mm ); 




// Gtandard test for COGenlnst derived clas?c;s. 
// Runs thz'ough normal persistent litccycle 'or 
// production instances. 
// 

1»include "stdgit.cc 
T.CLEANUP 

"> 

"77/////////////// //////////////////////////////// 

// Return covere».jr. infomation. 
// 

// NOTE: This is not to be modified by unit 
// test developers. 

.'//////////////////////////////////////////////// 
devoid 

i_Bc\sicHesource: :qryC.vverage { 
dtlnft aCovAry, 
dtlntt aN^umFuncs 
) const 

aCovAry = coverage; 
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J t ' " 

// T«rL 1: First Conscructor i Destructor 

// Set up test. . . . - 

Tl,2Fr_STARTi 'Ctorl and Ctor- j- *^<^ni00' *n*n*gcr na set up, scope cstiblijhed 



s erMfio^^^Ui """" ^^"^ constructor, then durnp the object, then delete :t. 
s.erKsg ir.s;l z newinstance( tg.vsgTest. EKVSCTirr NAy.z. Ec.yscTEST 1 r: 



© ^ 

(D_dei«telnstaneel tnssl ) : Slindard «rM»ff Piiimelers 

// Complet« Llfecycle t«si... 

TLirE.gQ Scope ended. Mgnary Hianagcr thccktd forleiks 
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// Tesi 1: QryMsalD 
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TZSTRUNdeclare («rMsgiJ 

«xtern *C* { 

^ dtChar • FAR PASCAL EXPORT e.«scnamen 

return ( 'erMsci • J ; 

) 

ClLlnt FAR PASCAL EXPORT t#scmain( IdtTestArgsi aTesiArgs I 
recurn( TESTRUN(er«$gi) ( aTescArgs ) ); 
) // end «xt«rn C 
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Siajxing t«5ti Copy Ctor • Copying Ctorl across HvtwirY Hgr». •t l\nm: 133. FiUi c j \vi«w\pro^\£d\ - . . 
EMORt KEMORY LEAX DCTTCTED IN >OORr »«M^CCA. In ftzt Copy Ctor - Copying Ctorl ucn»9 Mmry HQrs. 4C Line: 146 
ZMORt KDiORY L£AJC DCTCCTES IN KEXSRY KieaCER. in t*tL: Copy Ctor - Copying CLorl across MMsry Hgrs. «c Line: 14 6 

FXILO tesc: Copy Ccor - Copying Ccorl across Mnory Mors. «t lins: 146. Fil< : c: \vi«w\prodn\I<3\ . . . 



Scsrtlr.g test: qr/RsglD. at 11ns: 361, FiU: c : \vt*w\prodn\fd\«rrors\uc\ lnsp\«rHsgl .cpp 
CHETrXS: Dfprvssion: qryMsglOt ssgl ) «• 43. tn esse-. qrynsglD. ac Un«: 261. Fils: c : \vi«w\prodn\f d\ . . . 
PASS test: qryKsglD. ac lin»: 26a, FiU: ci \visw\prodn\fd\trrorsvuc \insp\srHsgi .cpp 
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CLAIMS : 

1 . A method for testing a subject class in an object-oriented digital data processing 
system, said method comprising the step of: 

(A) responding to a source signal defining said subject class to generate an inspection 
signal defining an inspection class having one or more members for 

5 (i) creating a test object as an instantiation of any of said subject class and a class derived 
therefrom, 

(ii) invoking one or more selected method members of said test object. 

(iii) generating a signal, hereinafter referred to as a report signal, reporting an effect of 
such invocation. 

10 2. A method according to claim K comprising 

(B) responding to said source signal to generate a test signal defining a test class thai 
comprises any of 

(i) said subject class, and 

(ii) an instantiable class derived from said subject class, and 

15 step (A)(i) includes the step of generating said inspection signal to define said inspection 
class to include one or more members for creating said test object as an instantiation iM said 
test class. 

3. A method according to claim 2. wherein 

step (B) includes the step of generating said test signal to define an instantiable test 
20 class that inherits one or more members of said subject class. 

4. A method according to claim 3, wherein 

step (B) includes the step of generating said lest signal to define said test class to 
substantially duplicate pure virtual functions of said subject class, absent constructs that 
denote those functions as having both pure and virtual attributes. 

25 5. A method according to claim 3, wherein 

step (B) includes the step of generating said test signal to define said lest class to 
substantially duplicate at least one constructor and a destructor of said subject class. 



6. A method according to claim 3. wherein 
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Step (A) includes the step of generating said inspection signal to define said inspection 
class to comprise one or more method members providing common reporting ser\'ices for 
invocation by said test suite members. 

13. A method according to claim 7, wherein 

step (A) includes the step of generating said inspection signal to define said inspection 
members to include method member functions corresponding to at least one constructor in 
said lest object, wherein each of those method member functions take substantially the same 
arguments as the corresponding constructor in said test object. 

14. A method according to claim 7. wherein 

step (A) includes the step of generating said inspection signal to define said inspection 
members to include method member functions corresponding to a destructor in said lest 
object. 

15. A method according to claim 7. wherein 

step (A) includes the step of generating said inspection signal to define said inspection 
members to include method member functions corresponding to at least one operator function 
in said lest object. 

1 6. A method according to claim 7. wherein 

step (A) includes the step of generating said inspection signal to define said inspccuoii 
members to have function names similar to those of the corresponding method members of 
the test object that they test. 

1 7. A rriethod according to claim L comprising the step of 

(B) responding to said inspection signal to create an inspection object as an instantiation 
of said inspection class, and 

(C) invoking one or more members of said inspection object to 

(i) create said test object, 

(ii) invoke one or more selected method members of said test object. 

(iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation. 
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(i) a comparison of results of invocation of one or more method members of said test 
object with one or more expected values thereof, and 

(ii) detection of a memory leak. 

26. A method according to claim 1 7, wherein 

said method includes the step of executing step (B) a plurality of times, each for 
invoking a different group of one or more selected method members of said test object. 

27. A method according to claim 1 7, wherein 

step (C)(ii) includes the step of invoking one or more method members of said 
inspection object, referred to hereinafter as inspection members, for testing corresponding 
method members of said test object. 

28. A method according to claim 27, wherein 

step (C)(ii) includes the step of invoking one or more method members one or more 
members of said inspection object, referred to hereinafter as test suite members, for 
exercising one or more of said inspection members. 

29. A method according to claim 28, wherein 

step (C)(ii) includes the step of invoking one or more lest suite members lo at least 

one of 

(i) test for memory leaks in connection with at least one of creation and destruction of 
said test object, 

(ii) test accessor and transformer members of said test object, 

(iii) test operator member methods of said test object, 

(iv) test members involved in persistence of said test object, and 

(v) test method members semantically unique to said test object. 

30. A method according to claim 28, wherein 

step (C)(ii) includes the step invoking one or more method members of said 
inspection object for invoking one or more test suite members. 



31. A method according to claim 1 7, wherein 
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36. A method according to claim 34, wherem 

step (B)(ii) includes applying at least one argument to one or more of said selected 
method members of said test object in connection with invocation thereof 

37. A method according to claim 36, wherein 

5 step (B)(ii) includes applying at least one argument to a constructor member of said 

test object in connection with creation of said test object. 

38. A method according to claim 34, wherein 

step (B)(ii) includes the step of preventing exceptions that occur during invocation of 
said one or more selected method members from discontinuing execution of steps (B)(ii) and 
10 (BXiii). 

39. A method according to claim 34. wherein 

step (B)(iii) includes comparing said result of such invocation with one or more 
expected values thereof, and generating said report signal to be indicative of such 
comparison. 

15 40. A method according to claim 39. wherein 

step (B)(iii) includes the step of storing a signal indicative of said effects in a duL» 
member of said inspection object. 

41. A method according to claim 34, wherein 

said method includes the step of executing step (B) a plurality of times, each lor 
20 invoking a different group of one or more selected method members of said test objcci. 

42. A method according to claim 4 1 . wherein 

step (B)(iii) includes the step of generating said report signal to be indicative ol Ji 
least one of 

(i) comparison of results of invocation of one or more method members of said test 
25 object with one or more expected values thereof, and 

(ii) detection of a memory leak. 



43. A method according to claim 34. wherein 
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responding to a verbosity control signal lo generate said report signal with a selected 
level of verbosity. 

50. Apparatus for testing a subject class in an object-oriented digital data processing 
system, said apparatus comprising: 

5 (A) code generator means for responding to a source signal defining said subject class to 
generate an inspection signal defining an inspection class having one or more members for 

(i) creating a test object as an instantiation of any of said subject class and a class derived 
therefrom, 

(ii) invoking one or more selected method members of said test object, 

10 (iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation, and 

(B) test harness means, coupled lo said code generator means, for responding to said 
inspection signal for creating an inspection object instantiating said inspection class, and for 
generating an inspection object invocation signal for invoking one or more members thereof. 

15 51. An apparatus according to claim 50. wherein 

said code generator means includes test class generating means for responding to said 
source signal to generate a test signal defining a test class that comprises any of 

(i) said subject class, and 

(ii) an instantiable class derived from said subject class, and wherein 

20 said code generator further includes means for generating said inspection signal to define said 
inspection class to include one or more members for creating said test object as an 
instantiation of said test class. 

52. An apparatus according to claim 50, wherein 

said code generator means includes means for generating said inspection signal to 
25 define said inspection class to include one or more method members, referred to hereinafter 
as inspection members, for testing corresponding method members of said test object. 



An apparatus according to claim 52. wherein 
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(a) said subject class, and 

(b) an instantiable class derived from said subject class. 

59. An apparatus according to claim 57, wherein 

said inspection object execution means includes means for applying at least one 
argument to one or more of said selected method members of said test object in connection 
with invocation thereof. 

60. An apparatus according to claim 57. wherein 

said inspection object execution means includes exception service means preventing 
exceptions that occur during invocation of said one or more selected method members from 
discontinuing at least reporting on effects of invocation of said test object. 

61. An apparatus according to claim 57. wherein 

said inspection object execution means includes means for comparing a result of 
invocation of said one or more selected method members of said lest object with expected 
results of such invocation, and for generating said report signal to be indicative of such 
comparison. 

62. An apparatus according to any of claims 57 and 59. wherein 

said inspection object execution means includes means for executing one or more 
member methods of said inspection object to generate said report signal. 

63. An apparatus according to any of claims 61. wherein: 

said inspection object execution means includes means responding to a verbosity 
control signal to generate said report signals with a selected level of verbosity. 

64. An apparatus according to claim 57. wherein 

said inspection object execution means includes means for executing one or more 
method members of said inspection object, referred to hereinafter as mspection members, for 
testing corresponding method members of said test object. 

65. An apparatus according to claim 64, wherein 
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for creating an inspection object instantiating an inspection class, and for generating 
an inspection object invocation signal for invoking one or members thereof, 

(B) inspection object execution means, coupled to said test harness means, for responding 
10 said inspection object invocation signal for 

. 5 (i) creating said test object, 

(ii) generating a test object invocation signal to invoke one or more selected method 
members of said test object, 

(iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation, 

10 (C) test object execution means, coupled to said inspection object execution means, for 
responding to said test object invocation signal to execute one or more selected method 
members thereof 

70. An apparatus according to claim 69. wherein 

said inspection object execution means includes means for creating said test object as 
15 an instantiation of a test class that comprises any of 

(a) said subject class, and 

(b) an instantiable class derived from said subject class. 

71 . An apparatus according to claim 69, wherein 

said inspection object execution means includes means for applying at least one 
20 argument to one or more of said selected method members of said test object in connection 
with invocation thereof. 

72. An apparatus according to claim 69, wherein 

said inspection object execution means includes exception service means preventing 
exceptions that occur during invocation of said one or more selected method members from 
25 discontinuing at least reporting on effects of invocation of said test object. 

73. An apparatus according to claim 69, wherein 

said inspection object execution means includes means for comparing a result of 
invocation of said one or more selected method members of said test object with expected 
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said inspection object execution means includes means for executing a method 
member of said inspection object for invoking one or more test suite members. 

80, An apparatus according to claim 69, wherein 

said inspection object execution means includes means for placing said digital data 
processor in a desired runtime environment. 




Figure 2 
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bool A(Int argl) , 



bool 

X_Cl«»fl : :A(P_Cla«e* Obj , 
Intargl) 

AnnounceStart(-A-) ; // report otart of teet 
AnnounceParameter(argl) ; // report parametere that will be 

// paaaed to member to be teoted 
bool t«tVal . Obj->A(argl); // invoke member 
AnnounceRtnValueit.tVal) ; // report member result 
AnnounceEnd(-A-) ; // report end of test 
return ( tatval ) ; // return member reeult 



38 
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Figure 4 
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Figure 8 
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